fix(ci): grant the secret-scanner reusable its required job permissions#72
Merged
Merged
Conversation
The scan job calls secret-scanner-reusable.yml, whose gitleaks job declares pull-requests: write (PR summary comment) and actions: read (workflow-run metadata) at job level. A called reusable workflow may only request permissions equal to or more restrictive than its caller, and this caller granted only the file-level contents: read — so GitHub refused the run at parse time. Every Secret Scanner run ended in startup_failure, meaning secret scanning has never actually executed in this repo. Grants the superset at job level, matching the canonical template and the 176 estate repos whose scanner already runs. No SHA pin is changed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
secret-scanner-reusable.yml deliberately retired TruffleHog as redundant
("gitleaks provides sufficient coverage at lower cost" — see the reusable's
header). The inline job survived here, fails, and turns the whole workflow red
even when gitleaks, rust-secrets and shell-secrets all pass — so the repo keeps
emitting ci_activity notifications after the startup_failure is fixed.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signed-off-by: Jonathan D.A. Jewell <6759885+hyperpolymath@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Every
Secret Scannerrun in this repo has been ending instartup_failure— meaning secret scanning has never actually executed here.Root cause
A called reusable workflow may only request permissions equal to or more restrictive than its caller. This is enforced when the workflow file is parsed, before a runner is allocated — which is why it surfaces as
startup_failurewith no logs and no annotations.secret-scanner-reusable.ymldeclares this on itsgitleaksjob:This caller granted only the file-level
permissions: contents: read, so the reusable was asking for more than the caller had, and GitHub refused the run outright.Evidence
Two repos pinning the identical reusable SHA behave differently based only on this block:
modshells(grants the superset) runs fine;verisimdb(does not)startup_failures. Estate-wide, 176 callers grant it and run; 26 did not and were all dead.Fix
Grant the superset at job level — byte-identical to the canonical template. No SHA pin is changed, so the scanned content and supply-chain posture are unaffected; this only lets the existing pinned scanner start.
Verified
On
hyperpolymath/vext, this exact change movedSecret Scannerfromstartup_failureto success, withgitleaks,rust-secretsandshell-secretsall allocating runners and passing.🤖 Generated with Claude Code